home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000107_nls@cse.iitb.ernet.in _Wed May 5 06:36:14 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  5KB
  1. Received: from relay2.UU.NET by optima.CS.Arizona.EDU (5.65c/15) via SMTP
  2.     id AA29979; Wed, 5 May 1993 06:36:14 MST
  3. Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
  4.     (5.61/UUNET-internet-primary) id AA07152; Wed, 5 May 93 09:36:15 -0400
  5. Received: from sangam.UUCP by spool.uu.net with UUCP/RMAIL
  6.     (queueing-rmail) id 093044.25943; Wed, 5 May 1993 09:30:44 EDT
  7. Received: by sangam.ncst.ernet.in (4.1/SMI-4.1-MHS-7.0)
  8.     id AA22498; Wed, 5 May 93 18:52:03+0530
  9. Received: from kailash.cse.iitb.ernet.in  by iitb.ernet.in
  10.     SENDMAIL Version (4.1/SMI-4.1-MHS-7.0) 
  11.     id AA16700; Wed, 5 May 93 18:39:21+0530
  12. Received: by kailash.cse.iitb.ernet.in (4.1/SMI-4.1)
  13.     id AA18047; Wed, 5 May 93 18:40:46 IST
  14. Date: Wed, 5 May 93 18:40:46 IST
  15. From: nls@cse.iitb.ernet.in (N L Sarda)
  16. Message-Id: <9305051310.AA18047@kailash.cse.iitb.ernet.in>
  17. To: tsql@cs.arizona.edu
  18.  
  19. This  is  in  reply  to the message from  Rick.  His  message  is 
  20. reproduced below :
  21. -----------------------------------------------------------
  22.  
  23. I think    that Nandlal's classification scheme has a lot going for it.
  24. The user's point of view has the advantage that    certain    types of
  25. queries    that are expected to be    more frequent than others can be
  26. emphasized.
  27.  
  28. I had a    difficult time understanding the classification    scheme,    perhaps
  29. in part    because    the explanation    was necessarily    short. There is    at
  30. most a sentence    or two on each of the portions of the scheme.
  31.  
  32. It also    is apparent that this classification scheme, while related in
  33. some ways to Christian's proposal, is also a quite different approach
  34. to organize queries. So    my question is,    is the proposed    scheme (1) an
  35. addition to, (2) a modification    of, or (3) a replacement for the
  36. existing strawman proposal?
  37.  
  38. If (1) or (2), could Nandlal modify the    strawman proposal,
  39. incorporating his recommended additions/modifications, and post    a new
  40. proposed classification    scheme?    If (3),    could Nandlal write it up, to
  41. the level of specificity and detail of the existing strawman taxonomy
  42. proposal, so that the community    could decide between them? Finally, it
  43. would be very helpful if Nandlal could provide an approximate time
  44. frame for doing    so. Much work needs to be done on the step following
  45. the taxonomy in    the next six weeks, and    we need    to move    beyond the
  46. taxonomy very shortly. (Of course, after the workshop there will be
  47. the opportunity    to start on the    second version of the benchmark,
  48. addressing things like aggregates; at that time    we could also address
  49. improvements to    the taxonomy.
  50.  
  51. -----------------------------------------------------------
  52.  
  53.  
  54. I will refer to the taxonomy proposed by Christian simply as  CSJ 
  55. Proposal in the following. It has the following advantages :
  56.  
  57. -   it   satisfies  the  three  criteria  listed  by   CSJ.   The 
  58. classification  is  comprehensive  (within the  confines  of  the 
  59. decision to exclude 'group-by' and 'having' features of SQL).
  60. - it leads to identification of orthogonal components (which  are 
  61. derived from SQL features).
  62. - It provides for suitable naming of classes and categories. User 
  63. oriented class names can be introduced here.
  64.  
  65. In my proposal, I took a different approach. I apologize for  its 
  66. poor  readability  and inadequate explanations. I gave  a  syntax 
  67. "road map" for defining various classes. I tried to keep out  any 
  68. SQL  bias from classification (which probably is not  essential). 
  69. My proposal intends the following :
  70.  
  71. - define classes which are user oriented
  72. -  identify  more  likely classes to check that  these  are  more 
  73. easily expressible in TSQLs
  74. -  make  classification  at higher level  by  employing  temporal 
  75. algebra level operations (rather than using only the time  domain 
  76. operations in select and where clauses of SQL).
  77.  
  78. Rick's observations are well-taken. In response to the questions 
  79. posed by him, my answers are as follows :
  80.  
  81. -  It is difficult to add to or modify CSJ's proposal to  include 
  82. my suggestions because the approaches are quite different.
  83. -  I could attempt to add the suggested classes (in my  proposal) 
  84. as certain classes/categories in CSJ proposal in Sec. 1.3, but  I 
  85. have problem in making them orthogonal.
  86.  
  87. Hence, I propose to make an alternative classification scheme.  I 
  88. will try to prepare a 'strawman proposal' for it. I will also re-
  89. structure my proposal totally to improve its readability. I  will 
  90. also barrow from CSJ's proposal wherever necessary and  possible. 
  91. It will probably be more SQL-oriented than my earlier proposal.
  92.  
  93. Time  frame  : I may be able to complete the  preparation  of  my 
  94. proposal  by May 15, 1993. This may probably be too late for  the 
  95. workshop. In that case, we could comment on it in future.
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.